如何遷移遺留資料庫的資料？

前一章已經確認哪些資料需要遷移、封存、保留查詢或刪除。接下來需要將核准遷移的資料放入目標資料庫，並且保留資料含義、關係與必要的歷史內容。

資料出現在目標資料庫，不代表遷移已經完成。目標系統必須能正確解讀資料，主鍵與外部鍵關係不能中斷，日期、數值及空值也要符合目標規則。遷移程序還需要能重複演練、記錄錯誤，並且在正式切換前處理遷移期間產生的異動。

遷移方法可以先按照資料庫產品與版本分成三類，再根據資料量、可停止寫入的時間及轉換需求選擇實際工具。

先確認資料庫產品與版本

本文按照來源與目標使用的資料庫產品分類。「相同資料庫產品」 是指產品名稱相同，例如 MySQL → MySQL、PostgreSQL → PostgreSQL。「不同資料庫產品」 則是產品名稱不同，例如 MySQL → PostgreSQL。

版本是否相同需要另外判斷。即使產品與版本相同，兩邊也不一定能直接交換所有內容，還需要確認字元集、文字定序（Collation）、時區、擴充項目及執行設定。版本升級時，則要以原廠列出的相容範圍與升級路徑為準。

這項分類只決定優先評估的方法。即使資料庫產品與版本相同，如果目標系統已重新設計資料模型，仍可能需要使用邏輯匯出、ETL 或自訂程式轉換資料。

建立所有遷移方法共用的基準

選擇工具前，需要先記錄來源與目標的差異，避免執行到一半才發現資料無法解讀。至少要確認下列內容：

1. 列出來源與目標的資料庫產品、版本、字元集、文字定序、時區、擴充項目與相關設定。
2. 列出需要處理的資料表、欄位、型別、主鍵、外部鍵、限制條件、索引、識別碼產生方式及資料量。
3. 確認每項資料的來源、目標位置、轉換規則、預設值，以及無法轉換時的處理方式。
4. 確認遷移期間是否能停止來源寫入。如果不能，就要定義如何辨識與同步後續異動。
5. 定義每個批次的完成條件、錯誤紀錄、重新執行方式及驗證項目。

來源與目標結構不同時，可以使用資料對應表保存轉換規則：

資料對應表需要和遷移程式一起管理。規則改變時，兩者都要更新，否則文件與實際結果就會逐漸不一致。

相同資料庫產品、相同版本如何遷移？

來源與目標使用相同資料庫產品及版本，而且目標資料結構沒有明顯改變時，可以優先使用資料庫原生的完整備份與復原。這類工具通常能同時處理資料、型別、限制條件、索引及其他資料庫物件，減少逐項重建的工作。

可以停止來源寫入時，流程相對單純：

1. 停止會新增或修改資料的功能，並且記錄停止寫入的時間點。
2. 建立內容一致的完整備份，記錄資料庫版本、備份時間與執行結果。
3. 將備份復原至獨立的目標資料庫，不直接修改仍在運作的來源資料庫。
4. 確認資料庫物件、資料筆數、關聯及目標系統讀寫結果。
5. 驗證通過後，再將目標系統切換至目標資料庫。

需要縮短停止寫入時間時，可以先建立完整副本，再使用原生複寫或 CDC 持續同步新增與異動的資料。正式切換時只需要停止寫入、完成最後一次同步並驗證差異。這種方式需要額外確認同步範圍，因為資料庫物件變更、識別碼目前值或部分設定未必會跟著資料異動一起複寫。

完整備份也未必包含資料庫以外的設定、檔案或相依內容。遷移清單需要分別標示備份會處理哪些項目，以及哪些項目要用其他方式建立。

相同資料庫產品、升級版本如何遷移？

版本升級會增加格式與行為不相容的風險。執行前需要先確認來源版本能否直接升級至目標版本，或必須先經過原廠指定的中繼版本。正式遷移應該保留來源資料庫，先在獨立目標資料庫完成升級與驗證。

可以按照相容條件選擇下列方法：

• 原廠明確支援來源備份直接復原至目標版本時，可以使用相容的備份與復原程序，再執行必要的升級步驟。
• 資料檔或備份格式無法直接使用時，可以透過原生邏輯匯出與匯入重建資料庫物件及資料。
• 原廠提供專用升級工具時，可以使用工具檢查不相容項目、轉換內部格式並記錄執行結果。
• 來源與目標版本支援跨版本複寫或 CDC 時，可以先完成基準資料，再持續同步異動，縮短正式切換所需時間。

邏輯匯出與匯入通常比完整備份更容易跨版本處理，但需要確認型別、語法、預設值、文字定序、識別碼產生規則與擴充項目是否仍具有相同行為。資料庫引擎升級與目標系統的資料模型調整也要分開處理，避免把兩種變更混在同一個無法定位錯誤的步驟中。

每一條升級路徑都需要先演練。演練結果要記錄執行時間、警告、失敗項目、修正方式及驗證結果，才能判斷正式切換需要保留多少時間。

不同資料庫產品如何遷移？

來源與目標使用不同資料庫產品時，欄位名稱相同也不代表資料可以直接轉移。數值精度、日期範圍、布林值、空值、文字長度、大小寫比較與自動產生識別碼的方式都可能不同。遷移前需要先完成結構與欄位對應，再選擇能實作這些規則的方法。

下列方法可以分別使用，也可以依資料特性搭配：

• ETL 工具適合建立可重複執行的擷取、轉換與載入流程，並且集中管理欄位轉換、批次範圍與錯誤紀錄。
• 資料庫轉換工具適合處理工具已支援的型別與資料庫物件，但仍要人工確認轉換後的資料含義與限制條件。
• 自訂遷移程式適合處理需要多個來源、複雜規則或目標系統資料模型的轉換。
• CSV 適合表格型資料、規則明確且需要人工檢視中介內容的情況。

使用 ETL 工具遷移

擷取、轉換與載入（Extract, Transform, Load, ETL）工具可以將資料遷移拆成三個可獨立檢查的階段：

1. 擷取：從一致的資料快照讀取來源資料，按照主鍵、時間或其他穩定條件切分批次，並記錄每批資料的來源範圍。
2. 轉換：按照資料對應表調整欄位名稱、型別、空值、日期、代碼、識別碼及資料關係，並將無法轉換的內容送至獨立錯誤流程。
3. 載入：按照主資料與相依資料的順序寫入目標資料庫，記錄成功與失敗筆數，並在每個批次完成後執行必要驗證。

ETL 工具可以集中管理資料連線、轉換步驟、執行順序與錯誤分流，但不能自行判斷欄位含義或正確的功能規則。資料對應表仍是轉換依據，工具中的每一項欄位對應、預設值與例外處理都要能回到已確認的規則。

為了讓流程可以演練及重新執行，ETL 工作至少要具備下列設計：

• 使用固定的來源快照或明確的擷取時間點，避免同一批資料來自不同狀態。
• 使用穩定條件切分批次並保存完成位置，讓失敗後可以從指定範圍繼續。
• 將正常、略過、錯誤與待確認資料分開記錄，不要讓工具自動忽略不相容內容。
• 將載入步驟安排成可驗證的順序，必要時先寫入暫存資料表，再移入目標資料表。
• 記錄流程版本、轉換規則版本、來源筆數、目標筆數、錯誤筆數及執行時間。

如果來源在完整載入期間仍會異動，還要確認工具是否支援增量擷取或異動資料擷取（Change Data Capture, CDC）。有些工具適合執行完整 ETL，但不負責持續擷取資料庫異動。這種情況需要搭配資料庫原生複寫、CDC 工具或可驗證的異動時間欄位。新增、修改與刪除都要分別測試，不能只確認新增資料。

選擇 ETL 工具時，需要比較下列條件：

• 工具是否支援來源與目標資料庫產品的實際版本，以及需要使用的欄位型別。
• 連接器是否支援完整載入、增量載入、刪除同步及 CDC，不能只確認產品名稱是否出現在支援清單中。
• 工具是否能實作欄位對應、型別轉換、代碼轉換、多資料表關聯與錯誤分流。
• 流程是否能保存批次進度、重新執行失敗範圍，並且輸出足以驗證的執行紀錄。
• 執行方式、維護成本、授權條件與支援週期是否符合後續演練及正式遷移需求。

下列工具可以作為評估起點。選定前仍要用具代表性的資料進行概念驗證（Proof of Concept, POC），確認連接器、型別轉換、處理量與錯誤復原方式符合實際需求。

工具名稱相同也可能因版本、連接器及執行方式而具有不同功能。正式採用前，需要使用實際來源與目標版本完成完整載入、失敗重跑、增量同步及資料驗證，不能只按照功能清單決定。

使用 CSV 遷移

CSV 只保存欄位順序與文字內容，不會保存欄位型別、主鍵、外部鍵、索引及資料庫限制。使用前需要固定下列規則：

• 固定文字編碼、欄位順序、標題列、分隔符號、引號及換行方式。
• 分別定義空值與空字串，避免匯入後失去原本差異。
• 統一日期、時間、時區、布林值、數值精度及特殊字元的表示方式。
• 按照主資料與相依資料的關係安排匯出及匯入順序。
• 保留來源主鍵，或建立新舊識別碼對應，讓相依資料能連回正確目標。
• 將無法轉換的資料寫入獨立錯誤紀錄，不要直接略過或改成未定義的預設值。

二進位資料、大型物件及複雜巢狀結構通常不適合直接放入 CSV。可以改用轉換工具或自訂程式處理內容，並在資料表中保存能重建關係的識別資訊。大量資料也需要分批匯出及匯入，避免單次工作占用過多執行資源或長時間鎖定資料庫。

CSV 與其他中介檔案可能包含個人資料或敏感資訊。遷移流程需要限制存取、加密保存、記錄用途，並且在演練或正式遷移結束後按照既定期限清除。

如何使用 ORM 遷移？

物件關聯對映（Object-Relational Mapping, ORM）工具常把「遷移」用於兩種不同工作，使用前需要先區分目的。

第一種是結構遷移。ORM 以版本化腳本建立或調整目標資料庫的資料表、欄位、索引及限制條件，適合管理目標系統的資料模型變更。這項功能不會自動搬移來源資料，也不能取代資料庫引擎的版本升級程序。

第二種是使用 ORM 撰寫自訂資料遷移程式。程式分別連接來源與目標資料庫，讀取來源模型、套用轉換規則，再將結果寫入目標模型。這種方式適合不同資料庫產品，或來源與目標資料模型差異較大的情況。

ORM 工具通常與特定程式語言或框架整合。選擇時要先確認目標系統採用的技術、資料庫支援範圍及遷移工作是否需要獨立執行，不需要只為了搬移資料而引入另一套程式語言或框架。

這些工具都能協助建立目標結構或撰寫資料轉換程式，但不會自動產生正確的欄位對應與功能規則。採用前仍要使用實際來源與目標版本驗證型別支援、產生的結構異動、批次效能及錯誤復原方式。

ORM 資料遷移程式需要明確處理下列工作：

1. 使用穩定且可排序的識別內容切分批次，記錄每個批次的起點、終點與處理狀態。
2. 只讀取轉換需要的欄位，避免載入不必要的關聯與內容。
3. 在寫入前驗證必要欄位、型別、代碼對照及資料關係。
4. 使用交易（Transaction）控制每個批次的寫入範圍，失敗時只復原該批次。
5. 設計相同批次重跑時不會重複建立資料的寫入規則。
6. 分別記錄成功、失敗與待確認項目，讓程序可以從已完成位置繼續。

ORM 逐筆建立物件及追蹤狀態可能產生額外負擔。資料量較大時，需要實際測量批次大小與執行時間，並且視需要搭配 ORM 的批次功能或資料庫原生批次匯入。複雜型別、資料庫特有功能或大量直接複製通常更適合原生工具，不需要為了統一程式寫法而全部改用 ORM。

讓遷移程序可以重新執行

正式遷移前通常會執行多次演練。程序如果只能從頭執行，單一錯誤就可能浪費大量時間。如果重跑會產生重複資料，又無法安全修正問題。因此，每次遷移都需要有可追蹤的執行紀錄。

每個批次至少記錄遷移版本、來源範圍、開始與結束時間、讀取筆數、寫入筆數、略過筆數、錯誤筆數及完成狀態。程式與轉換規則也要保存版本，讓結果可以對應到實際使用的內容。

重新執行可以採用下列方式：

• 寫入前檢查目標識別碼，存在時按照規則更新或略過，不存在時才新增。
• 先寫入暫存資料表，完成一批驗證後再移入正式資料表。
• 讓每個批次使用獨立交易，失敗時復原該批次並保留錯誤紀錄。
• 修正資料或轉換規則後，只重新執行受影響的資料範圍。

遷移程式不應該直接修改來源資料來掩蓋問題。需要清理或補正的內容，應該記錄原始值、轉換結果及核准的處理方式，讓演練與正式遷移使用相同規則。

如何驗證遷移結果？

只比較資料總筆數，可能看不出關聯錯置、數值截斷或代碼轉換錯誤。驗證需要從結構、數量、關係、內容與功能規則逐層進行。

抽樣資料需要涵蓋一般內容、邊界值、空值、特殊字元、較早資料及曾經轉換失敗的類型。每一項差異都要能分類為核准的轉換結果、來源資料問題或遷移錯誤。無法說明的差異不能直接列為通過。

驗證結果應該和遷移執行紀錄保存於同一次演練中。下一次執行才能比較錯誤是否已修正、時間是否符合切換安排，以及是否出現新的差異。

處理增量資料與正式切換

如果完整遷移期間來源資料仍會異動，只建立一次資料快照就會遺漏後續內容。遷移流程需要定義一個一致的來源時間點，並且記錄該時間點之後新增、修改與刪除的資料。

常見切換流程如下：

1. 從一致的資料快照建立目標資料庫的基準內容。
2. 使用原生複寫、CDC、異動時間或其他已驗證方式收集後續異動。
3. 重複演練增量同步，確認新增、修改與刪除都能正確套用。
4. 正式切換時停止來源寫入，等待處理中的工作完成。
5. 套用最後一批異動，執行資料驗證並確認沒有未處理差異。
6. 將目標系統切換至目標資料庫，再確認實際讀寫結果。

復原方案需要區分目標資料庫是否已經接受新寫入。尚未產生新資料時，可以停止目標系統並切換回既有系統。目標資料庫已經產生新資料時，則要先停止寫入，按照預先確認的方式保存、反向同步或處理這些異動，再決定是否切換回既有系統。直接切回來源資料庫可能遺失切換後的內容。

正式切換前，至少要完成一次包含完整遷移、增量同步、驗證、切換與復原的演練。只有各階段的負責人、執行時間、停止條件及結果都能確認，遷移流程才具備實際執行的基礎。

重點整理

• 資料庫遷移要先區分相同資料庫產品且版本相同、相同資料庫產品但升級版本，以及不同資料庫產品，再根據相容性、資料量與停止寫入時間選擇方法。
• 相同資料庫產品且版本相同時，可以優先使用原生完整備份與復原。需要縮短停止寫入時間時，可以搭配原生複寫或 CDC。
• 相同資料庫產品但升級版本時，需要按照原廠支援路徑選擇相容的備份與復原、邏輯匯出與匯入，或原廠升級工具。
• 不同資料庫產品需要明確定義結構、欄位、型別與識別碼對應。CSV 是其中一種中介格式，複雜內容可以改用 ETL、轉換工具或自訂程式。
• ETL 流程需要分別處理一致擷取、資料轉換、載入順序、錯誤分流及重新執行。選擇工具時，仍要按照連接器、轉換能力及增量同步需求評估。
• ORM 的結構管理與資料處理方式會受到目標系統技術與工具能力影響。選擇工具時，要評估產生內容的正確性與大量資料的批次成本。
• 可重新執行的遷移流程需要記錄批次範圍、處理結果、錯誤及轉換規則版本，並且從結構、數量、關係、內容與功能規則驗證結果。
• 來源資料持續異動時，需要先建立基準內容，再同步增量資料。正式切換與復原程序都要處理切換前後產生的異動。